1. Field of the Invention
The present invention generally relates to an environment for automated generation of web pages interfacing rich media. Particularly, the present invention relates to a method and a device is provided for making a media file accessible via a web page and, correspondingly, to a method and device installed at the streaming service provider's side for serving a user's request for hosting a media file to be streamed to a visitor's computer on its request.
2. Description of the Related Art
Rich media data extends traditional computer data formats into more natural data formats for the interaction of humans and computers by incorporating images, motion pictures, voice, audio, and video. Leading market, business, social, and technical indicators point to the growing importance of such digitally recorded content.
Furthermore, rich media data is getting more and more pervasive in Internet applications. All those Internet applications have different requirements and use cases, but they are all working with alike content data. Due to this fact, Internet applications are getting really complex and not easily customizable to individual requirements.
One of the key issues with rich media data is, however, transferring the huge amount of data through a network. In the past, data is transferred using the store & forward paradigm, i.e., the complete content is transferred before the data is presented. A prominent implementation of this paradigm is the File Transfer Protocol (FTP), one of the standard ways to transfer files throughout the World Wide Web. For conventional data this works fine, as the amounts of data to be transferred are comparably small. For audio and video clips, though, the latency time that passes between a request for rendering and the start of the rendering gets impractically long.
A couple of years ago another paradigm called streaming has emerged. Streaming allows the rendering of media to take place in parallel with the transfer of its content, which reduces latency times to a minimum. Streaming software always comes in pairs, a stream server pumping data continuously through the network and a player receiving the data and rendering it.
The player is always the part requesting a streaming data connection. While establishing such a data connection, the client sends so called meta data to the stream server, which identifies the requested rich media data object. In general, the meta data is used by the stream server to find the rich media object within its cache, but the meta data can also contain further information like access tickets, bandwidth information, offsets within the media etc.
In order to ensure the quality of the data stream, which in general means that the required bandwidth could be written to the network throughout the entire stream duration, current stream server require the rich media data object to reside on the local file system. So, every stream server, which likes to stream a rich media data object has to keep a copy within its local disk cache. Furthermore, a stream server has to be aware of the available system resources like CPU, memory, disk I/O capabilities, network connectivity, etc. If a new streaming request exceeds one of its resources the request has to be rejected in order to ensure the quality of established data streams.
In a distributed scenario like the Internet there could be a long distance between the stream server and the player. The data has to be transferred over an unknown number of nodes with an unpredictable overall bandwidth. So-called edge-servers are established to solve such kind of problems.
As described above, the creation and configuration requirements become more and more complex by using rich media content data applied with the services required or offered combining rich media data within today's Internet applications. Moreover, the time to market for these rich media Internet applications becomes shorter and shorter which forces requirements to handle these infrastructure and administration requests in very short time periods to be accessed from all over the world.
What can be seen from the above descriptions is that rich media services require a very complex infrastructure. In order to get acceptable media streaming services, a huge amount of distributed servers (edge-servers), hosting proxies services, distribution and caching services, streaming services, billing services, advertising services and metering services—to enable short access latency time—are required.
Building up, operating and maintaining this infrastructure with 24/7 QOS is very complex and expensive and needs high skilled operation personal. The entire infrastructure needed to present rich media in the Internet is quite expensive. In some of the business models this leads to unacceptable expenses for the users using these media offerings.
Therefore systems are currently appearing which offer Media Services to companies wanting to stream rich media to their end users without having the necessity to install and maintain all the infrastructure for streaming like stream servers, edge servers etc. The company who wants to include rich media into their Web Site can upload the media by simply invoking a standardized Web Service preferably with the help of a SOAP/XML like interface. A key is returned referring to that media and the company has as a subsequent step to include a CGI script or servlet into their Web Site which interacts with a second Web Service to get the so called Meta Media which the CGI script or servlet has to send to the browser of the end user requesting the rich media, so that the browser can finally contact the Media Service in order to get the requested content streamed to his system.
What can be seen from the above said is, that it is rather complex for a Web Designer to include rich media, even if a Media Service is used. Specific servlets or CGI scripts have to be programmed and included in the HTML pages and the designer of the Web Page has to know about streaming technologies, Meta Media and their proprietary formats, SOAP and other media related areas.